src/Table.tsx (1)

140-144: 对外 API onColumnResizeEnd 的命名与结构建议

命名与内部 colsWidths/colWidths 存在不一致；建议统一术语，避免 columnWidths vs colWidths 混用。同时，为提升查询效率与可读性，考虑将 columnWidths 从数组改为 Record/Map（O(1) 查找），或并行提供两种形式。

src/interface.ts (2)

66-66: 建议为 scrollbar 属性添加文档说明。

scrollbar 属性缺少 JSDoc 注释，建议补充说明其用途和使用场景，例如是否用于标识虚拟滚动条列。这将有助于其他开发者理解该属性的作用。

可以考虑添加类似如下的文档：

   className?: string;
   style?: React.CSSProperties;
   children?: React.ReactNode;
+  /** Column configuration with optional scrollbar metadata */
   column?: ColumnsType<RecordType>[number] & { scrollbar?: boolean };
   colSpan?: number;
   rowSpan?: number;

---

130-130: 建议为 resizable 属性添加详细文档。

resizable 属性作为列宽调整功能的核心 API，建议添加 JSDoc 注释说明：

• 该属性的作用（是否允许用户拖拽调整列宽）
• 默认值（未设置时的行为）
• 与其他属性的交互（如 width、minWidth 等）

这将帮助用户更好地理解和使用该功能。

可以考虑添加类似如下的文档：

   rowSpan?: number;
   width?: number | string;
   minWidth?: number;
+  /** Whether the column can be resized by dragging. Defaults to false. */
   resizable?: boolean;
   onCell?: GetComponentProps<RecordType>;

src/context/TableContext.tsx (1)

64-66: 回调重命名合理，但需处理旧字段歧义与文档说明

• onColumnWidthChange 命名清晰，但同时保留 colWidths（数组）与新增 colsWidths（Map）/colsKeys 会造成概念重复与状态分裂风险。建议标注 colWidths 为废弃，指引改用新组合。
• 建议为回调补充最小文档（单位/裁剪规则），避免二义性。

可考虑如下微调（仅类型注释与废弃标记）：

-  onColumnWidthChange: (columnKey: React.Key, width: number) => void;
+  /** width 单位：px；应为已按 minWidth/maxWidth 约束后的值 */
+  onColumnWidthChange: (columnKey: React.Key, width: number) => void;

-  colWidths: number[];
+  /** @deprecated 请改用 colsWidths + colsKeys；后续将移除 */
+  colWidths: number[];

src/Table.tsx (2)

392-396: useMemo 依赖使用 join 带来不必要开销与潜在碰撞

pureColsKeys.join('_') 每次 render 做 O(n) 字符串拼接，且当 key 含下划线可能造成误判。这里 colsKeys 仅回传 pureColsKeys 本身，useMemo 意义有限。建议简化：

- const pureColsKeys = getColumnsKey(flattenColumns);
- const colsKeys = React.useMemo(() => pureColsKeys, [pureColsKeys.join('_')]);
+ const pureColsKeys = getColumnsKey(flattenColumns);
+ // 直接使用或以引用为依赖即可
+ const colsKeys = React.useMemo(() => pureColsKeys, [pureColsKeys]);
+ // 或：const colsKeys = pureColsKeys;

---

447-450: 为 onColumnWidthChange 增加输入健壮性（NaN/负值/无穷）

拖拽过程中可能产生异常宽度，建议在入口处校验，避免状态抖动与布局异常。

- const onColumnWidthChange = React.useCallback((columnKey: React.Key, width: number) => {
+ const onColumnWidthChange = React.useCallback((columnKey: React.Key, width: number) => {
+   if (!Number.isFinite(width) || width < 0) {
+     return;
+   }
    updateColsWidths(widths => {
      if (widths.get(columnKey) !== width) {
        const newWidths = new Map(widths);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/VirtualTable/BodyGrid.tsx (1)

24-42: 在 useEffect 依赖中补充 onColumnWidthChange，避免闭包过期

这里的 effect 目前只依赖 columnsWidth，如果未来 TableContext 中的 onColumnWidthChange 被替换（例如内部 hooks 或 refactor），effect 不会重新执行，会继续使用旧回调，也会触发 hooks lint 警告。建议把它一并放进依赖数组：

-  React.useEffect(() => {
-    columnsWidth.forEach(([key, width]) => {
-      onColumnWidthChange(key, width);
-    });
-  }, [columnsWidth]);
+  React.useEffect(() => {
+    columnsWidth.forEach(([key, width]) => {
+      onColumnWidthChange(key, width);
+    });
+  }, [columnsWidth, onColumnWidthChange]);

当前实现因为回调本身是稳定的不会立刻出 bug，但按 hooks 规范补齐依赖会更安全一些。

Also applies to: 73-77

src/Table.tsx (2)

391-399: 列宽度追踪逻辑整体 OK，但 join('_') 依赖写法可以更直观一些

用 Map<React.Key, number> 存 colsWidths，再按 colsKeys 映射出 colWidths 并通过 useMemo 保持引用稳定，这个思路是合理的，也有利于减少下游 useMemo/useEffect 的无效重算。

不过当前用 pureColsKeys.join('_') / pureColWidths.join('_') 作为依赖 key 的写法可读性略差，而且存在极小概率的拼接冲突（例如特殊字符串 key）。可以考虑用更直接的写法来表达“当列定义或宽度数组实际变化时才更新”，例如：

-  const pureColsKeys = getColumnsKey(flattenColumns);
-  const colsKeys = React.useMemo(() => pureColsKeys, [pureColsKeys.join('_')]);
-  const pureColWidths = colsKeys.map(columnKey => colsWidths.get(columnKey));
-  const colWidths = React.useMemo(() => pureColWidths, [pureColWidths.join('_')]);
+  const colsKeys = React.useMemo(
+    () => getColumnsKey(flattenColumns),
+    [flattenColumns],
+  );
+  const colWidths = React.useMemo(
+    () => colsKeys.map(columnKey => colsWidths.get(columnKey)),
+    [colsKeys, colsWidths],
+  );

功能等价但更易读，也避免了手工 join 依赖的潜在问题；如果后续 profiling 发现确有性能差异，再针对性优化即可。

Also applies to: 447-456, 915-916, 971-977, 980-980

---

874-935: TableContext 新增字段及依赖基本正确，可顺手清理一些小瑕疵

TableContextValue 中新增的 onColumnWidthChange、colsWidths、colsKeys、colWidths、onColumnResizeEnd、onResizingChange、fullTableRef 等都已经同时出现在 value 和依赖列表中，能保证消费方在列宽/拖拽状态变化时正确更新。结合之前关于 context 依赖必须与字段保持同步的经验来看，这里整体是对的。Based on learnings, 这一点非常重要。

有两点可以顺便打磨下：

1. 依赖数组里 colWidths 出现了两次（行 977 和 980），虽然完全无害，但会迷惑后续维护者。
2. fullTableRef 本身是一个稳定的 ref 对象，把它放进 useMemo 依赖不会带来问题，但也不会随着 .current 的变化而重新计算 context；如果只是为了把 ref 传下去，其实可以不放在依赖列表里，让依赖更聚焦于真正决定渲染的数据/配置。

可以在不改变行为的前提下，把重复和不必要的依赖精简掉，使这一块更干净一些。

Also applies to: 936-996

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: bbb169
Repo: react-component/table PR: 1202
File: src/Table.tsx:903-904
Timestamp: 2024-11-08T12:53:09.293Z
Learning: 在 `src/Table.tsx` 文件的 React 组件 `Table` 中，即使 `bodyScrollLeft` 频繁更新，也需要在 `TableContextValue` 的 `useMemo` 依赖数组中包含 `bodyScrollLeft` 和 `headerCellRefs`，因为每次滚动时重新计算 `TableContextValue` 是解决该问题所必须的。